An Object-Oriented Programming System in TEX

This paper describes the implementation of an object-oriented programming system in TEX. The system separates formatting procedures from the document markup. It offers design programmers the benefits of object-oriented programming techniques. The inspiration for these macros comes from extensive book-production experience with W&X. This paper is a companion to Arthur Ogawa's "Object-Oriented Programming, Descriptive Markup, and TEX". The macros presented here constitute the fruit of a struggle to produce sophisticated books in a commercial environment. They run under either plain TEX or LATEX, but owe their primary inspiration to LATEX, especially in the separation of logical and visual design. The author hopes that future TEX-based document production systems such as LATEX^ and NTS will incorporate these techques and the experience they represent. Throughout this paper we refer to book production with W X . Many of the comments apply equally well to other TEX-based document processing environments. Design and Production Perspectives Certain problems routinely crop up during book production with LATEX. The majority fall into two general categories: those related to the peculiarities of a particular job and those regarding the basic capabilities of the production system. Peculiar documents. Strange, and sometimes even bizarre, element variants often occur within a single document. Without extremely thorough manuscript analysis these surprise everybody during composition, after the schedules have been set. The author received the following queries during production of a single book: 1. What is the proper way to set Theorem 2.1' after Theorem 2.1? 2. Small icons indicating the field of application accompany certain exercise items. How do we accommodate these variations? 3. Ths book contains step lists numbered Step 1, Step 2, . . . , and other lists numbered Rhubarb 1, Rhubarb 2, . . . How do we code these? Each variation requires the ability to override the default behavior of the element in question, or to create a new element. This is not difficult to accomplish ad hoc. The design programmer can implement prefur commands modifying the default behavior of a subsequent command or environment, add additional optional arguments, or create new commands and environments. But these solutions demand irnmediate intervention by the design programmer and also require that the user learn how to handle the special cases. A markup scheme in which optional attributes accompany elements provides a simple, consistent, and extensible mechanism to handle t h s type of production difficulty. Instead of the standard LATEX environment markup \begi n{theorem} [OOPS, A Theorem] . . . \end{theorem)